Integrated development environment (IDE) applications abstract the computer programming complexities and reduce software applications development time so as to enhance the productivity. An IDE allows a developer to concentrate more on the functionality of the application that is being created rather than concentrating on the writing code. An IDE may include a variety of components such as a source code editor, a compiler or interpreter, build automation tools, and a debugger and tools to build an executable, for example. Versioning control may be included to assist computer programmers manage the history of the development objects, e.g. source code. An IDE for object-oriented programming (OOP) often includes a class browser, tools to produce class hierarchy diagrams, and an object inspector, for example. An IDE can assist a developer in developing applications by allowing him to easily drag and drop objects onto a ‘form’ or onto a ‘canvas’ of the application that is under development. Thus, a developer may be required to write fewer lines of code, which reduces the time required to create an application. An IDE may combine several editor tools, each tool tailored to process objects of a specific type. State-of-the-art IDEs often provide plug-in options which allow users or commercial developers to integrate external tools and new object types.
However, not all of tools, object types and operations are intended to be used by anybody, anywhere. Depending upon user authorizations, user role, system configuration, client-specific customizing and other context information, access to certain types and operations and tools may be forbidden or restricted. FIGS. 1 and 2A-2B provide illustrative examples of user interfaces that are not especially well matched to the particular context in which they are used.
FIG. 1 is an illustrative drawing of a user interface screen display indicating that a user lacks authorization to ‘Save’ a class object. In this example, the user interface screen display is part of an object editor (software) tool that requires a user to have authorization to use it. Unfortunately, in this example, an authority check is implemented in the actual tool, and a restriction is not evident until the user tries to call the tool or worse, until the user tries to complete an already initiated operation. Specifically, in this example, the user called a function on the object type ‘class’. The user seeks to create a new class object type named ‘CL—0815’. In this example, only after the user has entered the object name and perhaps other information relating to the new class object and then selects ‘Save’, does a notification pop up to indicate that the user lacks authorization to create the new class object. Thus, the user's prior efforts to create a new class object are for naught, which is frustrating to the user. From a usability standpoint, this user interface behavior is quite poor because the authority restrictions are communicated too late.
FIGS. 2A-2B are illustrative drawings of user interface screen displays that include a menu (FIG. 2A) that offers a ‘Change’ operation and a warning (FIG. 2B) indicating that the ‘Change’ operation is not authorized. In this example, the user does not learn that he is not authorized to use the ‘Change’ operation until after he has selected it. User interface behavior is disappointing because authority restrictions are communicated to late.
FIG. 3 is an illustrative drawing of a user interface screen display showing a package list collection of object types contained within a ‘Package’, in which the ‘Check Configuration’ object type is not prominently displayed. The example package list is hierarchical. The root object type is ‘Package’, and the ‘Check Configuration’ object type is at the same hierarchy level as many other object types below the root. A certain object type or operation can be of particular importance for some users, roles or authorization groups, but not for others or it can be of high relevance in a certain system configuration or in a specific instance (client/tenant) of the system, but not in another system context or system instance. For users in some roles such as quality manager, for example, the ‘Check Configuration’ object type may be more important, and for ease of use it may be more convenient to such users to display that object type more prominently.
With the increasing complexity of IDEs, there has been a need for improvement in the ability to flexibly generate different user interface displays for use within an IDE that support differences in the availability and prominence of the displays of different object types and operations to different users in different situations.